Proposal · Risk & Governance — Growthsquare
Growthsquare
Book a call
PAGE 2 · RISK & GOVERNANCE

Built to be trusted with your team's data.

Security, ownership, and the freedom to walk away. The Check-In Hub runs on accounts you own, on a stack any competent developer can maintain, with no Growthsquare lock-in.

Trust commitments · PPR Check-In Hub risk & governance
1
Your data, your account CLIENT-OWNED
The database lives in a Supabase project PPR owns and controls. We build in it; we never hold the keys.
2
Code is a deliverable TRANSFERRED ON DELIVERY
Source, schema, and config hand over to PPR at the end of each phase. Standard Next.js / Supabase / Vercel stack, no proprietary lock-in.
3
Privacy by default Row-level security enforces per-group privacy in the database itself, not just in the UI. One team's check-ins stay invisible to other teams.
every commitment on this page maps to a concrete control, not a marketing claim
01 · DATA OWNERSHIP & LOCATION

Where the data lives is one question. Who controls it is the one that matters.

RESIDENCY Where the bytes physically sit.

A PostgreSQL database hosted by Supabase, on AWS infrastructure. Supabase is a US-based provider, so data is subject to US jurisdiction. For an internal sales-activity tracker with no client financial or identity data, this is a proportionate posture.

≠
CONTROL Who holds the account, the credentials, and the right to walk away.

The Supabase project is created under PPR's account. PPR holds the admin credentials from day one. Growthsquare gets developer access to build, and that access can be revoked at any time without taking the system down.

PPR owns the data

Every check-in, check-out, deal note, and agent entry is stored in a database PPR controls. Export it, back it up, or delete it without asking anyone.

PPR owns the code

Source code, database schema, and configuration are deliverables. On final payment of each phase, they transfer to PPR in full.

No Growthsquare lock-in

Standard stack (Next.js, Supabase, Vercel). Any competent web developer can read the code, run it, and extend it. No proprietary runtime, no custom DSL.

02 · SECURITY ARCHITECTURE

Five layers. Every hop encrypted.

Each request crosses a controlled boundary: HTTPS in transit, hashed credentials, rate-limited login, and row-level security scoping every query.

Proportionate to an internal sales tool. No over-claiming, no theatre.
LAYER 1 · CLIENT Agent or manager, on any device Mobile-first web app. No install, no shared device login, one account per person.
browser
HTTPS · TLS 1.3 · ENCRYPTED IN TRANSIT
LAYER 2 · APPLICATION Next.js app on Vercel Server-side rendering and API routes. No business logic in the browser, no secrets shipped to the client.
server
AUTH CHECK · BCRYPT PIN · RATE-LIMITED
LAYER 3 · AUTH Name + PIN, bcrypt-hashed, rate-limited PINs are never stored in plain text. Login attempts are throttled. Upgrade path to email/SSO in Phase 3 without re-architecting.
bcrypt
TLS · ENCRYPTED IN TRANSIT
LAYER 4 · DATA PostgreSQL via Supabase, RLS per group Row-level security enforces per-group privacy at the database. Even a bug in the app cannot leak one team's check-ins to another.
RLS · per-group
every hop encrypted · no shared credentials · audit trail on every entry
UPTIME 99.5% daily-use internal tool
LOAD TIME < 2s on mobile 4G
RETENTION Indefinite no auto-purge, ever
ACCESSIBILITY WCAG 2.1 AA forms & navigation
Role-based access · who sees what enforced by RLS
Agent sees and edits only their own check-ins and check-outs
Manager sees only the groups assigned to them (Renee sees Alpha + Beta, Pietro sees Beta, etc.)
Super-admin sees all groups (Jeff-level), plus settings and user management
ACCESS LOG {{ entry }}
03 · ACCESS CONTROL

"Everyone watches what everyone else is doing" ends here.

The Hub enforces per-group privacy at the database layer. Agents see their own entries. Managers see their assigned groups. Only the super-admin sees across teams.

The toggles are live. Watch the access log.
04 · RISK REDUCTION MATRIX

What changes the day WhatsApp stops being the system of record.

RISK
TODAY (WHATSAPP)
WITH CHECK-IN HUB
RESIDUAL
Lost history / no audit trail
Messages scroll away. "When they finish a task, the task disappears."
Immutable entries in Postgres, one per agent per day, timestamped and searchable.
LOW
Data leaks between teams
One shared thread. "Everyone watches what everyone else is doing."
Row-level security scopes every query to the caller's group. Cross-team visibility is a super-admin privilege, not a default.
LOW
Notes never reach the CRM
Client notes live in WhatsApp. "The clients have no notes."
Phase 2 syncs confirmed notes to the matching GHL contact record by ID, not by name.
MEDIUM (Phase 2)
Weak shared access
One WhatsApp group, no per-person identity, no login audit.
Name + PIN per agent, bcrypt-hashed, rate-limited, with an upgrade path to email/SSO.
MEDIUM
No accountability on commitments
Morning intentions and evening results are not comparable. Managers reconcile by hand.
Plan-vs-actual is the core view. Check-in and check-out sit side by side per agent per day.
LOW
05 · IP & TRANSFERABILITY

An asset PPR owns, not a dependency on us.

The Check-In Hub is built on a standard stack precisely so that any competent developer can pick it up. No proprietary runtime, no custom framework, no vendor-specific magic. If Growthsquare disappeared tomorrow, the system keeps running.

Ownership register transferred on delivery
Source code, database schema, config PPR · 100%
Supabase project + database contents PPR · OWNED ACCOUNT
Stack (Next.js / Supabase / Vercel) STANDARD · DOCUMENTED
Right to maintain with any developer NO LOCK-IN
full transfer on final payment of each phase · code is readable, commented, and deployed on infrastructure PPR controls

Trust is a design decision. It's documented here.

Every claim on this page maps to a concrete control in the build.